An entity relationship (ER) diagram is a graphical representation of an organization's data storage requirements. Entity relationship diagrams are abstractions of the real world which simplify a problem to be solved while retaining its essential features. Entity relationship diagrams have three different components: entities, attributes and relationships. Entities are the people, places, things, events and concepts of interest. Entities may represent collections of things, for example, an employee entity might represent a collection of all the employees that work for an organization. Individual members (employees) of the collection are called instances of the employee entity.
Entities are further described by their attributes or data elements. These are the smallest units of data that can be described in a meaningful manner. For example, an employee entity may have the following attributes: employee number, last name, first name, date of birth, telephone number, department, etc. Frequently, a meaningful relationship exists between two different types of entity. For example: employees work in a department, lawyers advise clients, equipment is allocated to projects, truck is a type of vehicle, etc.
There are potentially three types of relationships which can exist between two different entities: one-to-one, one-to-many and many-to-one relationships. A one-to-one relationship is when a single occurrence of an entity is related to just one instance of a second entity. For example, a roof covers one building; a building is covered by one roof. One-to-many relationships are when a single occurrence of an entity is related to many instances of a second entity. For example, a department has many employees. Many-to-one relationships are when many instances of an entity are related to one instance of a second entity. For example, many employees work for one department.
ER models are very flexible and by their nature it can be difficult to construct powerful calculations within them. Much of the complexity comes from the relationships. In simpler models, you only need to be concerned with attributes—for example: Sales−Cost=Profit. The power and the complexity comes when there is a desire to see something more interesting, such as sales to men for woman's apparel around Mothers Day, vs. sales to women for men's apparel around Fathers day. For this type of calculation, sales are described in terms of who bought them (men or women), when they were purchased (Mothers day or Fathers day) and the type of product (men's apparel or woman's). This requires filters on the relationship between the actual sales for a given type of product and another for the order for when it was purchased and the yet another for the customer who purchased it.